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PATENT 

IN THE UNITED STATES PATENT AND TRADEMARK OFFICE 

Applicant: David R. Tushie et al. 
Serial No.: Unknown 

Filed: Herewith Docket: 457.003US2 

Title: SYSTEM AND APPARATUS FOR SMART CARD PERSONALIZATION 

PRELIMINARY AMENDMENT 

BOX PATENT APPLICATION 
Assistant Commissioner for Patents 
Washington, D.C. 20231 

Please amend the above-identified patent application as follows: 

IN THE SPECIFICATION 

On page 1, line 3, in the heading, " Related Application ", replace "Application" with 
—Applications-. 

On page 1, line 4, before "non-provisional", insert -continuation of U.S. Patent 
Application No. 08/755,459, filed on November 22, 1 996, which in turn is a-. 

On page 1, line 5, after "April 15, 1996", insert -, both of which are incorporated herein 
by reference — . 



IN THE CLAIMS 

Please cancel claims 1-24 and add the following new claims: 

25. [New] A method for issuing portable programmed data carriers comprising: 

acquiring personalization data for a cardholder and equipment characteristic data; 
executing an external process specified by a card issuer; and 
transferring the personalization data to personalization equipment as specified by the 
equipment characteristic data and the external process to issue the data carrier. 



PRELIMINARY AMENDMENT 

Serial Number: Unknown 
Filing Date: Herewith 

Title: SYSTEM AND APPARATUS FOR SMART CARD PERSONALIZATION 

26. [New] The method of claim 25, wherein the external process modifies the personalization 
data before it is transferred to the personalization equipment. 

27. [New] The method of claim 25, wherein the external process acquires additional data to be 
transferred to the personalization equipment and controls the transfer of the additional data. 

28. [New] The method of claim 25, wherein the external process modifies the act of transferring 
the personalization data. 

29. [New] A system for issuing portable programmed data carriers comprising: 

a system interface for acquiring personalization data for a cardholder and equipment 
characteristic data, for interfacing with an external process, and for transferring the 
personalization data to personalization equipment as specified by the equipment characteristic 
data and the external process to issue the data carrier. 

30. [New] The system of claim 29, wherein the external process modifies the personalization 
data before it is transferred to the personalization equipment. 

31 . [New] The system of claim 29, wherein the external process acquires additional data to be 
transferred to the personalization equipment and controls the transfer of the additional data. 

32. [New] The system of claim 29, wherein the external process modifies the act of transferring 
the personalization data. 
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PRELIMINARY AMENDMENT Page 3 

Serial Number: Unknown Dkt: 457.003US2 

Filing Date: Herewith 

Title: SYSTEM AND APPARATUS FOR SMART CARD PERSONALIZATION 

REMARKS 

Claims 1-24, allowed in Applicant's prior application, are canceled and new claims 25-32 
are added; thus, claims 25-32 are now pending. The specification is amended to add a cross 
reference to the prior application. 

The application filing fee as calculated on the application transmittal sheet reflects the 
amendments to the claims described above. 

The Applicant respectfully requests that the preliminary amendment described herein be 
entered into the record prior to examination and consideration of the above-identified 
application. 

Respectfully submitted, 
DAVID R. TUSHIE ET AL. 
By their Representatives, 

SCHWEGMAN, LUNDBERG, WOESSNER & KLUTH, P.A. 
RO. Box 2938 
Minneapolis, MN 55402 
(612) 373-6939 
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System and Apparatus for Smart Card Personalization 



Related Application 
This application is a non-provisional application claiming benefit under 35 
U.S.C. § 119(e) ofU.S. Provisional Application No. 60/015,743, filed April 15, 1996. 

Field of the Invention 
The present invention is related to data storage devices and in particular to 
producing portable programmed data carriers such as credit cards, debit cards, 
identification cards, and other transaction cards. 

Background of the Invention 

Increasing numbers of organizations which issue transaction cards to their users, 
customers, or employees require cards tailored to meet the requirements of their 
particular service or application. These organizations also want the cards to contain 
data about the cardholder. Existing transaction cards encode such data in a magnetic 
stripe on the back of the card but the amount of data that can be held by a magnetic 
stripe is limited. A new type of transaction card embeds a microprocessor computer 
chip in the plastic of the card to greatly increase the card's data storage capacity. 
Additionally, sophisticated card applications specific to the card issuer can execute in 
certain varieties of the chips, and the chip may also contain a type of operating system. 
Transaction cards with embedded chips are referred to in the industry as portable 
programmed data carriers, more commonly called "smart cards." The chip in a smart 
card is programmed with initialization and/or personalization data at the same time as 
the surface of the card is being embossed and/or printed. 

The initialization data comprises three major types of information: application 
data, security data, and printed data. The application data is common to all cards for a 
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given card application and includes application program code and variables. The 
security data prevents fraudulent use of the card and is usually provided in the form of 
"secure keys." Printed data, such as a logo, bar codes, and various types of numerical 
information, are placed on the surface of the card. Some or all of the same data can also 
5 be embossed on the surface. Optical technology also can be employed to make part or 
all of the surface of the card into a storage medium with data accessible by an 
appropriate optical reader. 

Smart cards are also programmed with information specific to an individual 
cardholder through a process called "personalization." The personalization information 
10 for a smart card is similar to the personalization information currently contained on non- 
smart cards, such as the cardholder's name, account number, card expiration date, and a 
photograph. Because of its increased storage capacity, the chip in a smart card can 
contain additional data beyond the basic information on the standard transaction card 
including a graphical representation of the individual's signature, data defining the types 
1 5 of service the cardholder is entitled to, and account limits for those services. 

The smart card issuing process must control and report on each personalized 
card and the results of the personalization process. Extensive report and audit files thus 
must be maintained to support the card tracking requirements. 

Currently, a smart card issuing system must be tailored to meet the requirements 
20 of a specific card application that will be programmed on a specific type of smart card 
under the control of a specific card operating system and to format the data for the card 
to be compatible with a specific type of personalization equipment chosen to issue the 
card. The entire issuing system must be re-configured whenever any one of these 
variables (issuer application, smart card/card operating system, and/or personalization 
25 equipment) is changed, increasing the time and cost incurred by the issuer of the card in 
delivering personalized smart cards to its customers. Additionally, many of the current 
issuing systems lack a viable means to provide dynamic feedback regarding the status of 
any particular batch of cards in the process to the card issuer. 
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Furthermore, the smart card issuing systems in use today utilize a proprietary 
approach developed by either the card manufacturer or the personalization equipment 
manufacturer. To encourage sales of their respective cards or equipment, each 
manufacturer develops a unique personalization solution for a particular card 
5 application, and each solution is specific to a particular card issuer. These unique 

solutions are intended to optimize performance of the cards or equipment and thus do 
not permit a more inclusive, generalized personalization process that accepts any card 
operating system and/or work with any personalization equipment. 

As the demand for smart cards increases, a smart card issuing system which 
1 0 permits the card issuers to use any type of personalization equipment to handle multiple 
types of smart cards, and their attendant operating systems, and to embed the issuers' 
specific card applications along with the required cardholder data in any of the various 
types of smart cards is required. 

15 Summary of the Invention 

A smart card personalization system maintains a database containing card 
application data, issuer format template data, card operating system data, and 
personalization equipment data to permit a card issuer to dynamically change card 
applications, card and card operating systems, and/or personalization equipment in a 

20 card issuing process without the necessity of modifying the card issuer's interface to the 
issuing process. 

The smart card personalization system issues portable programmed data carriers, 
or smart cards, by first acquiring a data format identifier, a card operating system 
identifier, a personalization equipment identifier, an application program identifier or 
25 identifiers, and personalization data for a cardholder from a card issuer management 

system. The identifiers permit the system to address data stored in a data structure, such 
as a database, and specify the particular data needed by the system for each card to be 
issued. Because each card issuer formats its personalization data differently and may 
have multiple data formats, the smart card personalization system has a database of data 



format templates that enable it to interface with multiple card issuer management 
systems. The system acquires the format template defining the personalization data 
used by a particular card issuer from a record in the database identified by the data 
format identifier. The system uses the data format template to translate the 

5 personalization data from the card issuer's format into an internal format recognized by 
the components of the system. The system uses the card operating system identifier and 
application program identifier(s) to acquire programming control commands for an 
operating system pre-loaded in a microprocessor chip embedded in the card, and 
application data, in the form of code and/or variables, for an application program type or 

10 types from the database. The system also acquires the equipment characteristic data for 
the personalization equipment to be used to issue the smart card using the 
personalization equipment identifier. Once the system has acquired all the data 
necessary to issue the smart card it transfers the programming control commands, the 
application code and variables, and the translated personalization data to the 

1 5 personalization equipment as specified by the equipment characteristic data. 

Alternatively, no data format identifier is passed by the card issuer because the 
data format template is derived from data in the application data record or because the 
format of the personalization corresponds on a one-to-one basis with the internal format 
used by the system. The card issuer may also substitute the data format template record 

20 for the data format identifier so the system does not need to reference its database of 
format records. 

Another feature of the smart card personalization system is its card management 
function. The smart card personalization system collects information regarding the card 
issuing process and reports this information to the card issuer management system. 
25 Smart cards may include one or more "secure keys" that are programmed into 

the chip to prevent fraudulent use of the card. The appropriate secure key data is 
obtained by the smart card personalization system from secure key records maintained 
by the card issuer, or another security source, and then transferred to the personalization 
equipment. The security source also provides security functions that are used by the 



smart card personalization system to ensure the integrity and secrecy of data during the 
transmission of data to and from the system and within the system during the smart card 
personalization process. 

The smart card management system performs the functions described above 

5 through a series of software modules executing on a computer or multiple computers. 
One module is a card issuer management system interface which acquires the data 
format identifier, the card operating system identifier, the personalization equipment 
identifier, the application program identifiers), and the personalization data for a 
cardholder from the card issuer management system. The card issuer management 

1 0 system interface then uses the data format identifier to acquire the format template that 
defines the personalization data and translates the personalization data into the common, 
internal data format. A card operating system interface module acquires the 
programming control commands for the card operating system type specified by the 
card operating system identifier. A card application interface module uses the 

1 5 application program identifiers) to determine which type(s) of application program is to 
be placed on the card and acquires the specified application code and variables. A 
personalization equipment interface module is responsible for the acquisition of the 
equipment characteristic data for the personalization equipment type specified by the 
personalization equipment identifier, and further for transferring the programming 

20 control commands, the application code and variables, and the translated personalization 
data to the personalization equipment in accordance with the requirements stipulated by 
the equipment characteristic data. 

The reporting and security functions are provided by a tracking/report module 
and by a secure key management module. 

25 The smart card personalization system uses an underlying data structure, such as 

a database, residing in a computer storage medium to organize the data necessary to 
issue the smart cards. The data structure comprises several different types of data 
elements and uses "indices" or "identifiers" to quickly access specific data. There are 
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four main data elements in the system: a data format element, a card operating system 

element, an application program element, and a personalization equipment element. 
The data format element contains a template that defines the format of the 

personalization data used by the card issuer. The data format element may be stored in 
5 a database containing data format elements for various card issuer and the information 

stored in the data format element is accessed through the data format identifier. 

Alternatively, the data format element may be derived at the time the card is issued from 

data in the application program element(s) so that the application program identifiers) 

passed by the card issuer identify the data format. When the data format of the 
1 0 personalization data corresponds exactly to the internal format used by the smart card 

personalization system, the data format template is logically implied which creates a 

virtual data format element for the issuing process. 

The card operating system element holds the programming control commands 

that direct the card operating systems controlling a smart card chip and is accessed 
1 5 through the card operating system identifier. 

The application program element(s) contains application data, such as program 

code and variables, required by the applications associated with various card issuers; 

application data is accessed through an application program identifier(s). 

Operating parameters for various types of personalization equipment used to 
20 issue smart cards are stored in the personalization equipment element and accessed 

through a personalization equipment identifier corresponding to the ty£e of the 

personalization equipment to be used during an issuing run. 

Special configurations of the smart card personalization system support card 

issuers that do not need the full flexibility of the system described above. 
25 The smart card personalization system addresses the weakness in the prior art by 

providing a centralized interface of inputs and outputs to the smart card personalization 

process which is designed to dynamically accommodate changes in the issuing process. 

The system interfaces to any issuer management system, manages the transfer of 

cardholder data and card applications to the particular personalization equipment used, 



and collects statistics for real-time and off-line inquiries to support critical management 
and reporting functions. The system maintains a database of issuer data formats, card 
operating systems, card application programs, and types of personalization equipment. 
This database enables the system to handle any combination or permutations of the data, 
5 thus improving cost and time to market for the issuer. Furthermore, the system 
interfaces with various card security methodologies to reduce fraud. 

Brief Description of the Drawings 
Figure 1 A is a block diagram representing a smart card issuing process that 
1 0 incorporates a smart card personalization system. 

Figure IB is a functional block diagram of input and output connections for the 

smart card personalization system shown in Figure 1 A. 
Figure 1C is a functional block diagram showing software modules and data 
structures which comprise one embodiment of the smart card 
15 personalization system shown in Figure IB. 

Figure 2 is the functional block diagram of the embodiment of Figure 1 C with the 

addition of a security module to manage keys used for smart cards. 
Figure 3 is a functional block diagram of another embodiment of the smart card 
personalization system showing a minimal configuration to manage 
20 multiple types of cards and personalization equipment. 

Figure 4 is the functional block diagram of the embodiment of Figure 3 with the 

addition of a module to manage multiple card operating systems. 
Figure 5 is the functional block diagram of the embodiment of Figure 4 with the 
addition of the security module. 
25 Figure 6 is the functional block diagram of the embodiment of Figure 3 with the 

addition of a module to manage multiple card applications. 
Figure 7 is the functional block diagram of the embodiment of Figure 6 with the 
addition of the security module. 
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Figure 8 is a high level flow chart for computer software which implements the 

functions of the smart card personalization system. 
Figure 9 is a functional block diagram of an alternate embodiment of the smart 

card personalization system using software modules and data records. 
Figure 10 is a high level flow chart for computer software which implements the 

functions of the embodiment of the smart card personalization system 

shown in Figure 9. 

Figure 11 is a data field chart for a card framework template record used by the 

embodiment of the smart card personalization system shown in Figure 9. 
Figure 12 is a data field chart for a data format template record used by the 

embodiment of the smart card personalization system shown in Figure 9. 
Figure 13 is a data field chart for a card application data record used by the 

embodiment of the smart card personalization system shown in Figure 9. 
Figure 14 is a report format showing sample items tracked by the smart card 

personalization system. 

Description of the Embodiments 
In the following detailed description of the embodiments, reference is made to 
the accompanying drawings which form a part hereof, and in which is shown by way of 
illustration specific embodiments in which the invention may be practiced. These 
embodiments are described in sufficient detail to enable those skilled in the art to 
practice the invention, and it is to be understood that other embodiments may be utilized 
and that structural, logical and electrical changes may be made without departing from 
the spirit and scope of the present inventions. The following detailed description is, 
therefore, not to be taken in a limiting sense, and the scope of the present inventions is 
defined only by the appended claims. 

The leading digit(s) of the reference numbers in the Figures usually correspond 
to the figure number, with the exception that identical components which appear in 
multiple figures are identified by the same reference numbers. 
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Issuing Smart Cards 

Standard transaction cards such as regular credit cards are familiar to most 
people. A transaction card usually has information about the cardholder, such as name 
and account number, printed and/or embossed on the surface of the card. Transaction 

5 cards frequently contain a magnetic stripe which is encoded with cardholder data as 
well. The process of printing/embossing/encoding the cardholder data on each 
transaction card is known as "personalization." Each transaction card also undergoes a 
process known as "initialization" in which certain types of information common to all 
cards in a batch, such as an issuer identifier and batch number, are placed on the card. 

1 0 A smart card differs from a standard transaction card in that a computer 

microprocessor chip is embedded in the plastic of the card to greatly increase the card's 
data storage capacity. In some varieties of smart cards, the card manufacturer pre-loads 
the chip with one of several possible card operating systems and the operating system 
controls the programming of the chip during the personalization process. 

15 Additionally, sophisticated card applications specific to the card issuer may execute in 
certain varieties of the chips. 

The initialization data for a smart card comprises three major types of 
information: application data, security data, and printed data. The application data is 
common to all cards for a given card application and includes application program code 

20 and variables that are programmed into the chip. The security data, usually provided as 
secure keys or security functions, validates the data on the card and prevents fraudulent 
use of the card. Printed data, such as a logo, bar codes, and various types of numerical 
information, are printed on the surface of the card. Some or all of the same data may 
also be embossed on the surface. Optical technology also may be employed to make 

25 part of the surface of the smart card into a storage medium with data accessible by an 
appropriate optical reader. 

The personalization information for a smart card is similar to the personalization 
information currently contained on non-smart cards, such as the cardholder's name, 
account number, card expiration date, and a photograph. Because of its increased 



storage capacity, the chip in a smart card may contain additional data beyond the basic 
information on the standard transaction card including a graphical representation of the 
individual's signature, data defining the types of service the cardholder is entitled to, 
and account limits for those services. 

5 

Smart Card Personalization System 

Figure 1 A shows components of a smart card issuing process that incorporates 
an embodiment of the smart card personalization system of the present invention. The 
smart card personalization system 100 receives data from a card issuer management 

1 0 system 150 (typically proprietary to the card issuer), translates the data into a data 
stream, and outputs the data stream to personalization equipment 130 which 
personalizes the smart cards 160. The card issuer management system 150 manages the 
cardholder data and determines the type of card to issue, the card applications to embed 
in the card, and what personalization equipment to use to issue the card for a particular 

1 5 cardholder. The card issuer management system is frequently a computer program as 
illustrated in Figure 1A, but the smart card personalization system 100 is capable of 
receiving data from alternate inputs, such as a person inputting the data from a 
telephone keypad. 

The smart card personalization system 100 is illustrated in Figure 1 A as a 
20 software program executing in a computer. As described below, the smart card 

personalization system 100 accesses database records which define various types of 
cards and card operating systems, card applications, and personalization equipment. 
The logical functions of the software and the database may be distributed among 
computers in a client/server network or centralized into a single processor. The 
25 functions may also be distributed across processors connected through standard local 
area networks, wide area networks, dedicated phone lines or other communication 
means used to loosely couple processors. The software program executes under an 
operating system such as Unix, Windows 95°, or Windows NT®, and on industry- 
standard workstation and/or personal computer hardware. 

10 



The system 100 controls card printers, embossing devices, and integrated or add- 
on smart card interface devices collectively represented in Figure 1 A as personalization 
system 130. Personalization equipment 130 also represents such devices as large 
volume card printer/embossers, small volume card printer/embossers, automatic teller 

5 machiners (ATMs), point of sale terminals, unattended kiosks, personal computers, 
network computers, and on-line telecommunication devices. Because of their 
investment in existing non-smart card personalization equipment, many card issuers do 
not purchase entirely new smart card personalization equipment but instead augment 
their existing personalization equipment with a smart card interface device which 

1 0 programs the chip in the card while the older device performs the printing and 

embossing functions. In such a configuration, the computer system executing the smart 
card personalization system 100, or "host," may be physically connected to both devices 
or to only one of the devices. In the latter case, the host controls the directly-connected 
device and has a logical connection to the other. The physical connection between the 

1 5 devices and the host varies according to the manufacturer and model of the device. 

Common industry standard connections include serial RS232, SCSI (Small Computer 
System Interface), Ethernet, and serial TTL (Transistor-Transistor Logic). In addition, 
some devices require a proprietary bus connection. 

The connections between the smart card personalization system 100 and the card 

20 management system 150 and the devices 130 may also be implemented through 
standard local area networks, wide area networks, dedicated phone lines, or other 
remote communication infrastructure used to transfer data. The use of such remote 
connections when personalizing smart cards is described in U.S. Patent No. 5,524,857 
issued on July 9, 1996, to Laing, et al. Alternate connections will be apparent to those 

25 skilled in the art and are within the scope of the invention. 

Figure IB is a block diagram of one embodiment of the smart card 
personalization system illustrating the logical connections between the smart card 
personalization system 100 and functions employed by a card issuing organization to 
issue smart cards. Cardholder data maintained by the card issuing organization contains 



information about each individual cardholder, such as name, account number, card 
expiration date, and applicable services. Various ways of inputting the cardholder data 
into the card issuer management system 1 50 are shown in phantom as cardholder data 
152 in Figure IB. The card issuer management system 150 may receive the cardholder 

5 data on computer media, such as magnetic tape, floppy disk, or CD ROM. 

Alternatively, the cardholder data 152 may be input through an on-line connection such 
as a general switched telephone network, a packet-switched network, i.e., the Internet, a 
dedicated line, or a cable/satellite television signal. Additional ways in which the 
cardholder data 1 52 may be input to the system 150 will be apparent to those skilled in 

10 the art. 

In addition to the card issuer management system 150, the card issuer typically 
has an existing reporting capability 154 with which the smart card personalization 
system 100 interfaces so that the card issuer can review statistical information 
maintained by the system 100. An external security source, also provided by the card 

15 issuer and shown as secure key manager 1 1 1 and secure key database 128, provides 

security functions that work in conjunction with the card issuer management system 150 
and the smart card personalization system 100. Figure IB also illustrates an alternate 
embodiment of the smart card personalization system 100 which supports a card issuer 
that has add-on smart card interface devices. The system 100 directs a portion of the 

20 personalization information to the older personalization equipment 130 and the 

remainder of the data to a post-processor 132 in the smart card interface device 132 
which programs the chip. These functions are explained in detail below. 

The embodiments of the software program for the smart card personalization 
system 100 shown in the following Figures function as combinations of code modules 

25 with each module executing a specific part of the issuing process. In these 

embodiments, the modules are coupled through defined input and output program calls, 
and are also coupled to the data structures through standard data query commands that 
provide access to the data stored in the data structures. The communication protocols 
between the modules, and between the modules and the data structures vary depending 



on the language in which the modules are written and upon the underlying data 
management system employed to support the database. 

Figure 1C is a more detailed functional block diagram of the smart card 
personalization system 100 of Figure IB without the external security functions. Figure 

5 1C shows the internal connections between software modules and database records that 
enable the smart card personalization system 100 to combine multiple types of issuer 
data formats, card operating systems, card applications and personalization equipment 
when issuing smart cards. 

The smart card personalization system 100 provides a customized card issuer 

10 management interface 101 to a card issuer management system 150. In this 

embodiment, the card issuer management system 150 passes personalization data from a 
cardholder database 152 to the system 100. Each software module within system 100 
expects the personalization data to be passed to it in a particular, internal format. 
Because the personalization data is in an external format defined by the card issuer that 

1 5 often differs from the internal format(s) expected by the software modules, the 

personalization data is translated by the system 100 into the internal format(s) using the 
data format template. The system 100 may acquire the data format template through a 
data format identifier passed by the card issuer that the system 100 uses to acquire an 
optional data format template record 120 (shown in phantom in Figure 1C) as illustrated 

20 by an optional connection between the record 120 and the card issuer management 
system interface 101. Alternatively the card issuer passes the data format template 
record to the system 100 instead of the data format identifier. In another embodiment, 
the data format template may be derived from the data in the card application record 124 
that is specified by an application program identifier passed by the issuer as illustrated 

25 by an optional connection between the card application database 124 and the card issuer 
management system interface 101. 

In a further alternate embodiment of Figure 1C, security functions are provided 
internal to the smart card personalization system 100, by passing security functions into 
the system as part of the card application record. 

13 



A further alternate embodiment in which the personalization data format 
matches the internal format is also shown in Figure 1C. Because no translation between 
the external and internal formats is necessary in this embodiment, no data format 
template is needed so the data format record 120 and the connections between the card 

5 issuer management system interface 101 and the data format record 120 and the card 

application database 124 are not present. The data format record may 120 be composed 
of a plurality of tables which instruct the system 100 as to the proper parsing of the 
personalization data or a simple list that indicates the order in which the fields of the 
cardholder data record appear as will be apparent to those skilled in the art. The various 

1 0 alternate procedures for determining the format of the personalization data described 
above are implicit in all the embodiments of the smart card personalization system 100 
described herein. 

Using a card identifier provided by the card issuer management system 150, a 
card operating system interface module 103 retrieves programming control commands 
15 specific to the card operating system 122 for the microprocessor chip that is embedded 
in the type of card being issued. The programming control commands direct the 
encoding of the chip with the personalization data and the card application(s) chosen by 
the card issuer. 

Each card application comprises program code and variable data that is stored in 
20 the database as application data 124 and is identified by an application program 
identifier. The card issuer management system 150 passes one or more program 
application identifiers to the system 100 which are used by a card application interface 
module 105 to acquire the corresponding application data 124. 

The personalization equipment that the card issuer plans to use to issue the batch 
25 of cards is defined by a personalization equipment identifier. A personalization 

equipment interface module 107 acquires equipment characteristic data 126 specific to 
the type of personalization equipment 130 corresponding to the personalization 
equipment identifier. The personalization equipment interface 107 also acquires the 
programming control commands, the application code and variables, and the translated 



personalization data, and transfers all of this data to the personalization equipment 130 
as specified by the equipment characteristic data 126 to issue the smart card. 

An alternate embodiment of the system 100 supports a card issuer that has 
augmented their existing personalization equipment with a smart card programming 

5 device by having the personalization equipment interface 107 direct a subset of the 
translated personalization information to the older personalization equipment 130 and 
the remainder of the data to a post-processor 132 in the smart card programming device. 

The smart card personalization system 100 also provides a tracking/report 
module, or engine, 109 that collects statistical information from the other modules in the 

1 0 system 1 00 and formats the statistical information for output as hard-copy reports 1 54 
or as input to a reporting function in the card issuer management system 150. Because 
this statistical information is being gathered in real-time, the card issuer management 
system 150 can interactively query tracking/report module 109 to obtain statistics about 
the smart card personalization system as it is executing. Examples of items monitored 

1 5 by the tracking/report module 109 are shown in Figure 14. 

In an alternate embodiment shown in Figure 2, the smart card personalization 
system 100 includes a security source in the form of a secure key manager module 1 1 1 
and secure key database 128. When a smart card is manufactured, the vendor includes 
security architecture on the chip to prevent unauthorized programming. The security 

20 architecture implementation is commonly dependent on the application(s) programmed 
onto the chip. For example, the secure keys programmed in a stored value application 
would be different than the secure keys programmed in a health care application. The 
security architecture implementation also varies depending on the type of card: some 
cards require a single secure key which enables chip programming while others require 

25 multiple secure keys to enable chip programming and to perform additional security 

functions. Figure 2 illustrates the basic functions of the secure key manager 1 1 1 when 
interfacing with the security architecture on a card that requires multiple secure keys. 

As shown in Figure 2, the secure key data is stored in the secure key database 
128 which is external to the smart card personalization system 100 and maintained by 
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the card issuer or other security source. Extending the secure key manager 1 1 1 to 
handle more or fewer secure keys, and to interface with a secure key database managed 
by the smart card personalization system 100 itself, is dependant on the application, 
operating system, and personalization equipment being used in the specific card issuing 
application, and will be apparent to those skilled in the art. 

The secure key manager 1 1 1 also provides additional mechanisms to ensure 
secure key data authentication, data integrity and data secrecy. In one embodiment, 
secure key data authentication is accomplished through the implementation of various 
encryption methods. Secure key data integrity is achieved through digital signature 
mechanisms that use public keys to ensure that secure key data is being transmitted and 
received from valid sources. Secure key data secrecy is ensured by encrypting the 
transmitted data with a private key that is shared with the data receiver and which the 
data receiver uses to decrypt the data upon receipt. 

After the system 100 receives a secure key record from the secure key database 
128, the secure key manager 1 1 1, in conjunction with the card operating system 
interface 103 and the card application interface 105, perform the secure key 
authentication, data integrity and data secrecy functions. The system 100 then transfers 
the secure key data to the personalization equipment 130 through the personalization 
equipment interface 107 along with the other data for the card. 

In an alternate embodiment, the secure key manager 1 1 1 passes security 
information to the other modules of the smart card personalization system 100. For 
example, portions of the card holder data, such as the PIN (Personal Identification 
Number) code, may be encrypted by the card issuer management system 1 50 prior to 
passing the data to the smart card personalization system 100. The card issuer 
management system interface 101 retrieves the encryption key from the secure key 
database 128 through the secure key manager 1 1 1, and decrypts the data prior to 
encoding or programming the PIN code into the magnetic stripe and/or the chip. 

In a further alternate embodiment, the secure key manager 1 1 1 is a code "hook" 
into the smart card personalization system 100 which provides a gateway connection for 
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an external security source that supplies the required security functions. An example of 
such an external security source is a security manager program written by a third party 
that manages a security database of secure keys and/or security functions similar to 
secure key database 128. The security functions may be either external routines 
executed by the security manager, or code modules passed by the security manager 
which are then executed by the smart card personalization system 100 to provide the 
required security functions, or a combination of both. 

Figure 3 illustrates a minimal configuration of the smart card personalization 
system 100. In this embodiment, only the card issuer management system interface 
modules 101 and the personalization equipment interface modules 107 are enabled in 
the software. This embodiment permits card issuer to use the system 100 to personalize 
non-smart cards, thus saving the cost of having two separate personalization systems, 
while permitting the card issuer to use multiple data formats and multiple types of 
personalization equipment. Figure 3 also illustrates an additional alternate embodiment 
that includes the tracking/report module 109 as described above in conjunction with 
Figure 1C. 

In a still further alternate embodiment, the smart card personalization system 
100 shown in Figure 3 encodes data onto an optical transaction card when optical- 
encoding equipment is used as the personalization equipment 130. 

Figures 4 and 5 depict still further alternate embodiments that are implemented 
when the card issuer does not program a card application on the smart card chip. These 
embodiments allow the card issuer to issue multiple card types with their attendant 
variety of operating systems on multiple types of personalization equipment without 
having to reconfigure the smart card personalization system 100. As described above in 
conjunction with Figure 1C, Figure 4 includes the modules that support reporting and 
post-processing. Figure 5 illustrates the embodiments of Figure 4 with the addition of 
the secure key manager module 1 1 1 that provides security to the card operating system 
interface 103 for transmission to the personalization equipment 130. 
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Similarly, Figures 6 and 7 illustrate embodiments to support a card issuer that 
uses the chip on a smart card only as a data storage device for a card application, and so 
does not have an operating system executing on the chip. Smart card personalization 
system 100 supports multiple card applications for multiple card types issued with 
multiple types of personalization equipment. Figures 6 and 7 are analogous to Figures 4 
and 5 except that the secure key manager 1 1 1 provides secure keys and/or functions to 
the card application interface 105 instead of the card operating system interface 103. 

Figure 8 is a high level flow chart for one embodiment of software which 
implements the functions of the smart card personalization system 100 described above. 
The software acquires a personalization equipment identifier for a batch of transaction 
cards to be issued from the card issuer management system at block 801 . Depending on 
the type of cards to be issued, the software also acquires a program application 
identifier(s) and/or a card operating system identifier at the same time. The software 
then acquires the particular data format template corresponding to the format of the 
personalization data through one of the procedures described above (block 803). At 
block 805, the system acquires the equipment characteristics for the personalization 
equipment to be used to issue the batch of cards from the personalization equipment 
record specified by the personalization equipment identifier. 

If a card operating system identifier was passed by the card issuer management 
system (block 807), the software retrieves the programming control commands from the 
card operating system database record corresponding to the card operating system 
identifier at block 809. Blocks 81 1 and 813 perform the same logic for a card 
application, retrieving the application data, such as code and/or variables, from the 
database. At this point, the software has acquired the common data necessary for all the 
cards in the batch and begins looping through the logic which issues cards for the 
individual cardholders. 

The card issuer management system passes the personalization data for a single 
cardholder to the software (block 815) which translates the data items from the format 
defined by the data format template into an internal format used by the modules of the 
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smart card personalization system (block 817). If the card chip contains security 
architecture that requires secure keys (block 819), the software acquires the secure key 
data necessary to perform the secure key functions from the appropriate secure key 
source at block 821. 

The software is now ready to transfer data to the personalization equipment to 
program the card. If the card is protected by secure keys, the secure key functions are 
performed and the secure key data is transferred at block 823. Then the programming 
control codes for the chip operating system, if applicable, are transferred (blocks 825 
and 827); next the application code and/or variables are transferred if they are needed 
(blocks 829 and 831). Finally, the cardholder's personalization data that was translated 
into the internal format is transferred (block 833). 

After the data has been transferred to the card, the software adds the appropriate 
values to the statistics it collects for the card issuer management system at block 839. If 
more cards in the same batch remain to be issued (block 841), the software returns to 
block 815 and acquires the personalization data for the next cardholder. Otherwise, the 
software determines if the card issuer management system has a different batch of cards 
to issue (block 843) and returns to block 801 to acquire the necessary information to 
repeat the cycle for the new batch. If no further cards are to be issued, the software 
exits. 

The mechanisms by which the card issuer management system 150 passes the 
necessary data to the smart card personalization system 100 and the order in which the 
smart card personalization system processes the data from the card issuer management 
system may be changed without exceeding the scope of the invention. Different 
arrangements are dictated by the specific environment in which the system 100 operates 
as shown in the alternate embodiment illustrated in Figures 9 and 10. 

In Figure 9, a security module 91 1 acts as a gateway into the smart card 
personalization system 100 for a security source such as security manager 940 and 
security database 942 shown in Figure IB as 1 1 1 and 128 respectively. The security 
manager 940 controls access to the security database 942 and connects into the security 
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gateway 91 1 to perform the necessary security functions for the smart card 
personalization system 100. The security gateway 91 1 is coupled to the card issuer 
management system interface 901 which allows the interface 901 to request that the 
security manager 940 decrypt personalization data passed in an encryption format by the 
card issuer management system 950. The security gateway 91 1 is also coupled to the 
card application interface 903 and the card operating interface 905 so that it can supply 
the necessary secure keys and/or security functions to those interfaces as explained 
above in conjunction with Figure 2. 

Furthermore, the embodiment of the smart card personalization system 100 
shown in Figure 9 acquires the application data 922 specified by the application 
program identifier prior to acquiring the programming control commands specific to the 
card operating system 924 using the card identifier. This embodiment permits the 
personalization data and the application data to be translated into the internal format 
prior to retrieving the programming commands for the card operating system 924 and 
the equipment characteristic data 926, thus speeding the processing of each smart card. 

Standard transaction cards have data printed and embossed on the surface of the 
card and/or data encoded in a magnetic stripe on the card. With a smart card, data may 
also be stored in an internal memory area within the microprocessor. The same data 
may be placed on the surface of the card, in the magnetic stripe and also in the chip 
memory. The exact configuration of the data in and on the card will vary depending on 
the type of smart card being issued and the requirements of the card issuer. 

Figure 10 is a high level flow chart of the embodiment shown in Figure 9 and, in 
conjunction with Figures 1 1, 12 and 13, further illustrates how different mechanisms 
may be used to implement the smart card personalization system 100. The card issuer 
management system 950 passes a card framework template that defines the 
configuration of the smart card to the smart card personalization system 100 at block 
1001. 

Figure 1 1 illustrates one embodiment of the data layout for the card framework 
template record 1 100. The microprocessor chip identifier 1 101 and the card operating 
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system identifier 1 102 (if present) are specific to the type of smart card to be issued. 
The master file definition 1 103 contains control information such as the chip source and 
the last date the chip was altered. The system file definitions 1 104, 1105, 1107 contain 
addresses for the location of the system files within the memory of the chip. The 
system files are used by the card operating system and contain information such as the 
PIN code(s) for the card and applications, and algorithm tables. In the embodiment 
shown in Figure 1 1, the master file and the system file definitions conform to the 
International Standards Organization (ISO) directive number 7816-4. 

The next three sections of the card framework template record 1 100 define the 
arrangement of data on the surface and magnetic stripe of the card. If information is to 
be printed on the card, such as the cardholder's photograph 1 109, the location on the 
surface of the card to print such data is passed by the card issuer management system 
950 in the printing template of the card framework template record 1 100. Similarly, the 
locations on the surface of the card to emboss data is passed in the emboss template, and 
the arrangement of the data to be encoded in the magnetic stripe is passed in the mag 
stripe template. The emboss data is illustrated in the card framework template record 
1100 as the cardholder's name (EMName) 1111, account number (EMAcct) 1113, and 
expiration date (EMXdat) 1 1 15 and the magnetic stripe data by the account number 
(MSAcct) 1 1 17 and the expiration date (MSXdat) 1119. The number of data items in 
the printing, emboss, and mag stripe templates will vary depending on the configuration 
of the smart card desired by the card issuer as will be apparent to those skilled in the art. 

If the card issuer wants card applications programmed into the chip in the smart 
card, the card issuer passes the application program identifiers to the smart card 
personalization system 100 in the sections 1121,1 123, 1 125 of the card framework 
template record 1 100. Each application may have specific security functions associated 
with it (1 127, 1 129, 1131) and that information is also passed by the card issuer 
management system 950. The card framework template record 1 100 also contains the 
personalization equipment identifier 1 123 for the personalization equipment to be used 
to issue the smart cards. 
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In an alternate embodiment, the smart card personalization system 100 stores 
commonly used card framework template records in an internal database so that the card 
issuer management system 950 needs to pass only a card framework template identifier 
that identifies which card framework template record is to be used for a particular batch 
of cards. 

The smart card personalization system 100 acquires the data format template for 
the personalization data from a pre-defined location specified by the card issuer at block 
1003. If the card issuer has passed a data format identifier to the system 100, the data 
formate template record corresponding to the data format identifier is retrieved from the 
data format database 920. Alternatively, the card issuer may pass the data format 
template record itself. When neither the data format identifier nor the data format 
template record is passed to the system 100, the format of the personalization data is 
determined by the card application data as explained in more detail below. 

An example of a data format template record is shown in Figure 12. The data 
format template record 1200 defines an hypothetical layout of the personalization data 
records in the cardholder database 952 in which the account number 1201 is the first 
field, the cardholder's name 1202 is the second field, and the expiration date of the card 
1205 is the third field. In one embodiment, the personalization data records are comma- 
delimited records so no data field lengths are necessary to define the record format. 
Thus the data format template record 1200 shown in Figure 12 completely defines the 
structure of the following example of a comma-delimited personalization data record to 
the smart card personalization system 100: 133444999922,Mary Jane Smith,0299. 

The smart card personalization system 100 acquires the application data for the 
card application, or applications, 922 corresponding to the application program 
identifiers, if any, that were passed by the card issuer management system 950 at block 
1007. If no application program identifiers are passed, the smart card personalization 
system 1 00 acquires default application data (block 1 008). The default and/or the 
application data in the card application data record(s) corresponding to the application 
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program identifier(s) are inserted into the corresponding sections, i.e., 1 121 , 1 123, 1 125, 
of the card framework template record 1 100. 

One embodiment of the layout of a card application data record is shown in 
Figure 13. The first field in the card application data record 1300 is the application 
name 1301 . As with other computer-based application programs, a card application 
processes data from external sources such as an automatic teller machine or internal 
sources such as data files encoded into the microprocessor's memory. Using the smart 
card causes the appropriate application to be executed by the microprocessor and the 
application, in turn, accesses the internal files to retrieve or store data. To access 
internal data, the card application data record contains pointers to application files in the 
chip memory (1302, 1305, 1037) and also the location of fields within the application 
files. Some of the fields are initialized with data from the cardholder database 952 
when the card is issued. The application data 1300 includes an address 1303 to a 
cardholder file located in the chip memory and defines the cardholder file as containing 
three fields: the cardholder's name (ICName)1309, the account number (ICAcct) 1311 
and the expiration date (ICXdat) 1313. Additional internal data is stored in other 
application files and the layout of those additional files is also defined by the 
application data 1300. 

If the chip embedded in the smart card contains an operating system as specified 
by the card framework template record, the smart card personalization system 100 
acquires a set of programming control commands for the operating system from the card 
operation system database 924 at block 1011. The programming control commands for 
each operating system includes commands for functions such as creating and accessing 
files in the memory of the chip, reading and writing records in the files located in chip 
memory, along with security commands that authenticate PIN (Personal Identification 
Number) codes and control transactions that change monetary amounts stored in the 
chip. 

The smart card personalization system 100 acquires the equipment characteristic 
data corresponding to the personalization equipment identifier in the card framework 
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template record from the personalization equipment database 926 at block 1013. 
Included in the equipment characteristic data is a set of personalization programming 
control commands which control the operation of the personalization equipment. As is 
the case with the card operating systems, the personalization control commands are 

5 proprietary to the vendor of the equipment but typically include commands directed to 
the administration, formatting, and production of smart cards. 

When the smart card personalization system 100 has acquired all the data 
necessary to define a smart card, it is ready to accept personalization data records 952 
from the card issuer management system 950. As each personalization data record 952 

1 0 is passed at block 1 0 1 5, the smart card personalization system 1 00 uses the data format 
template, if present, to translate the personalization data into an internal format, and the 
card application data and card framework template to map the personalization data into 
variables in a command script written in an internal scripting language at block 1017. 
The translation and mapping process is described further below. Alternate 

1 5 embodiments which use a standard programming language such as Basic, Java or C 
instead of the internal scripting language are within the scope of the invention. 

The smart card personalization system 1019 checks for security requirements for 
the various components of the smart card issuing process. In the embodiment of the 
card framework template shown in Figure 1 1, the security requirements for the 

20 applications are specified by the card framework template record 1 100 at block 1019. 
If there are security requirements, the smart card personalization system 100 acquires 
secure data and/or functions from the security manager 940 and adds the functions into 
the internal script at block 1 021 . An alternate embodiment of the smart card 
personalization system 100 passes the identifiers of the card operating system and the 

25 personalization equipment, as well as the application program identifier, to the security 
manager 940 which retrieves the appropriate security data and/or functions from the 
security database 942. The security functions typically use data from additional 
sources, including data stored in internal chip files, personalization data 952, the 
operating system database 924, the card application database 922, combined with the 



algorithm tables stored in the chip or from an external security module, such as the 
security manager 940, to perform the secure key authentication, data integrity, data 
secrecy and other security processes described above in conjunction with Figure 2. 
Once the internal command script is completed, it must be translated into the 

5 proprietary programming control commands native to the card operating system (if 
present) and to the personalization equipment so that the personalization data is 
transferred to the smart card. In this embodiment, the translation is performed by a 
script language interpreter at blocks 1025 and 1027 using the information acquired from 
the card operating system database 924 and the personalization equipment database 926. 

10 At block 1029, the smart card operating system 100 passes the interpreted script 

to the personalization equipment which then executes the programming control 
commands to emboss/print, encode and program the appropriate personalization data 
onto the surface, and into the magnetic stripe and chip respectively of the smart card. 
As before, if the card issuer has elected to purchase an add-on smart card programming 

15 device to attach to its existing personalization equipment, an alternate embodiment of 
the smart card personalization system 100 directs the control commands for the 
embossing and encoding to the personalization equipment 930 and the control command 
for the chip to the post-processor 132 in the smart card programming device. 

When the issue process has been completed for one card, the smart card 

20 personalization system 100 acquires the next personalization data record if there are 
additional cards of the same type waiting to issue (block 1033). Otherwise, the smart 
card personalization system determines if there is another batch of smart cards of a 
different type waiting to issue (block 1001) and begin the issuing process again by 
acquiring a new card framework template record from the card issuer. 

25 The following example uses sample data to further describe the processing 

performed by the embodiment of the smart card personalization system 100 shown in 
Figures 9 and 10. The card issuer management system 950 requests the initiation of the 
issuing process by sending the smart card personalization system 100 a card framework 
template record, application program identifier(s), a card operating system identifier, a 



personalization equipment identifier, and optionally a data format template identifer or a 
data format template record. In this example, the card issuer management system 950 
passes an application resource template record shown below that contains the identifiers 
The system 100 acquires a data format template using one of the procedures specified 
above and explained in more detail below in conjunction with the sample cardholder 
data records. 

Application Resource Template Record 

[Ai] 

DFT=CARD1.DFT 
C AT=C ARD 1 .CAT 
CID=CHIPX.CID 
CPT=CARD1.CPT 
SOURCE=Al 

The first statement in the record marks the beginning of information for a particular 
application, in this case application " Al ". The next four statements define the 
identifiers for the card framework template record (DFT), the card application record 
(CAT), the card operating system record (CID) and the personalization equipment 
record (CPT). The final statement is the name of a file created by the card issuing 
management system 950 that contains the cardholder data record(s). The card issuing 
management system 950 inputs the cardholder data as either a single request or a 'batch' 
of requests for cards to be issued. 

The system 100 retrieves the records corresponding to the identifiers from the 
database. The system 100 then uses the information contained in the card framework 
template and data format template to set up an internal "script," which it later interpretes 
into the specific commands contained in the card operating system and personalization 
equipment records that instruct the personalization equipment to process the 
personalization data and issue the card for each cardholder. 

Two sample cardholder data records 952 are shown below. 
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Cardholder Data Records 
Smith ? James A 12653683091245 A 0998 A 041052 A mmmm 
5 Anderson,Sue A 39485003984138 A 0297 A l 10248 A mmmm 

In these records, the format defined by the card issuer places the account name 
(cardholder name) in the first field followed by the account number, expiration data, 
date of birth, and medical data. 

10 The system 100 uses the data format template to interpret each cardholder data 

record 952 as it is processed. The system 100 also uses the data format template and 
card application records 922 to validate the data 952 ensuring proper data and format. 
An example of a data format template corresponding to the format of the sample 
cardholder records shown above is shown in the first line of the table below. The James 

1 5 Smith personalization data record is included in the table to show the correspondence 
between the data format template and the fields of the cardholder data record. The data 
format template equates each field in the cardholder record with an internal label, %1, 
%2, etc., which corresponds to the internal order used within the system 100. 

20 Data Format Template Record 

j %1 j %2 |%3 | %4 | %5 | 

Smith, James A 12653683091245 A 0998 A 041052 A mmmm 

25 The example shown above represents the simplest case in which the fields of a 

cardholder data record 952 are arranged in the internal order used by the smart card 
personalization system 100. This one-to-one correspondence means that the system 100 
does not have to translate the cardholder data fields into the internal field order. In such 
a case, the data format template record is unnecessary. Thus, in a further alternate 

30 embodiment, the card issuer does not pass a data format identifier to the smart card 
personalization system 100, but instead passes an indicator, such as a flag, which 
informs the system 100 that no data format template is needed because the cardholder 
data fields are in a one-to-one correspondence with the internal field order. The system 
100 acts on the indicator by bypassing the translation step. 
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A more complex example shown next is one in which the fields of the 
cardholder data record 952 and the data within the fields are out of order relative to the 
internal system order. In this case, translation is necessary. 



5 Cardholder Data in Issuer Format 

1234567891245 James Smith 0998 041052 mmmm 
Cardholder Data Translated into Internal Format 
Smith,James A 12653683091245 A 0998 A 041052 A mmmm 
10 The system 100 uses the data format template to translate the data fields into the 

internal order as shown above. The translation may result in the physical rearrangement 
of the data fields or may be a logical rearrangement in which the data format template is 
invoked as a key each time a field from the cardholder data record is referenced by the 
system 100. Various data format templates designed to translate different arrangements 
1 5 of cardholder data will be apparent to those skilled in the art as will the substitution of 
tables of field equivalences or a set of parsing instructions or other mechanisms for the 
simple table used above to illustrate this example. 

The card framework template record describes the structure of the chip on the 
card. In the sample shown below, the $MF entry defines a root directory (3F00), while 
20 $DF entries define a medical application (5F20), and an accounting application (5F10). 
Within each directory are application-specific files defined by $EF entries, such as 6F00 
containing the account name and 6F10 containing the account number. All file 
descriptive data resides in the card framework template and is referenced at various 
times during the smart card issuing process. 



28 



Card Framework Template Record 
$CHIP=3 1 02,MEM=81 92,SIZE=N1 0 
5 $MF PATH=x3F00,TAG=ROOT,TITLE='Root Directory ',SIZE=D7 194 

$DF PATH=x3F005F10,TAG=ACCT,TITLE='Acct Data\SIZE=D2048 
$DFPATH=x3F005F20,TAG=MED,TITLE='Medical',SIZE=D1024 
$EF PATH=x3F003 100,TAG=ICCID,TITLE='Issuer 
ID' ,FORMAT=T,SIZE=Dl 0 
1 0 $EF PATH=x3F005F205E00,TAG=MED 1 ,TITLE='Medical 

profile',FORMAT=T,SIZE=D80 
$EF PATH=x3F005F 1 06F00,TAG=NAME,TITLE=' Acct 

Name',FORMAT=T,SIZE=A30 
$EF PATH=x3F005F 1 06F 1 0,TAG=ACCTID,TITLE=' Account 
15 No.',FORMAT=T,SIZE=N14 

$EF PATH=x3F005F 1 06F20,TAG=EXPIRE,TITLE=Expire 

Date' ,FORMAT=T,SIZE=N4 
$EF PATH=x3F005F106F30,TAG=BIRTH,TITLE=' Account Holder 

Birthdate' ,FORMAT=T,SIZE=N6 

20 . — 

The card application record 922 "maps" the cardholder data 952 to the data 

fields used by the application. The sample card application record 922 shown below 

has its data entries arranged in the sequence in which they are processed by the smart 

card personalization system 100. 
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Card Application Record 
$VL ICCID VALUE=1234509876 
5 $VL MED1 %5,TYPE=A 

$VL NAME %1,TYPE=A 
$VL ACCTID %2,TYPE=N 
$VL EXPIRE %3,TYPE=N 
$VL BIRTH %4,TYPE=N 
10 $VL FMTACCT %2(l-4)-%2(5-9)-%2(10-14) 

The ICCID entry contains the chip identifier. Each of remaining entries, except 
for FMTACCT, maps a "tag" to the field in the cardholder data record 952 that contains 
the information (as defined in the data format template shown above) and specifies the 
1 5 type of data in the field. Thus, the MED1 tag represents the fifth field in the cardholder 
data record 952 and the data is in alpha format. The FMTACCT entry breaks the 
second field in the cardholder data record 952, i.e., the account number, into sections 
and inserts hyphens between the sections. 

The card operating system record 924 contains the programming control 
20 commands necessary to program the chip on the card. The sample card operating 

system programming control commands shown below are taken from the ISO directive 
number 7816-4 and are not the internal proprietary commands of any particular card 
operating system. 
25 Card Operating System Record 

SELECT A0A4000002%F 
WRITE A0D0%O%L%D 
READ A0B0%O%L%D 
30 RESET VALUE-xFF 

Each entry in the example record above contains a tag followed by the 
corresponding command in the native language of the card operating system. Variable 
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parameter fields are indicated by "%" followed by a letter and are filled in with the 
appropriate cardholder data as each individual card is processed. 

The personalization equipment record 926 contains personalization equipment 
characteristic data, such as instructions that define the actual sequence and steps 
5 necessary to issue a complete card on a specific set of personalization equipment. The 
sample instructions used in this example are fictitious and do not represent the internal 
proprietary instructions for any particular personalization equipment. 

Personalization Equipment Record 

10 - 

$EMBOSS 

#EMB#%FMTACCT% A %NAME% 

SENCODE 

#ENC#%%%ACCTID% A %NAME% 

15 SIC 

#\@# 
@ICCID 
WRITE ICCID 
@NAME 

20 SELECT ACCT 

SELECT NAME 

WRITE NAME 

@ACCTID 

SELECT ACCTID 
25 WRITE ACCTID 

©EXPIRE 

SELECT EXPIRE 

WRITE EXPIRE 

$PR 

30 — 
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As each card is issued, the personalization equipment characteristic data shown 
above is serially processed in four steps defined by the entries preceded by a "$." The 
card application record 922 is used to determine the value of the variable parameter 
fields in each instruction. 

The $EMBOSS instruction is a single stream of data that begins with the control 
sequence #EMB# which notifies the personalization equipment that the data that 
follows should be embossed on the card. Each data field in the instruction is enclosed 
in a pair of percent signs. In this case, the first data field is FMTACCT, or the 
formatted account field as defined in the card application record 922. The system 100 
searches the card application record 922 for the FMTACCT entry and creates the string 
"1265-36830-91245" from the second data field in the first sample cardholder record 
952. The next field, NAME, is taken from the first data field in the cardholder record 
952. Thus, the emboss instruction for the first sample cardholder record 952 becomes 
#EMB%1265-36830-91245%%Smith,James%. 

The $ENCODE instruction causes the system 100 to process the cardholder data 
to be encoded on the magnetic stripe of the card in the same fashion as the emboss 
instruction. Additional control characters in accordance with following IATA 
(International Air Travel Association) and ISO standards are inserted into the command. 
The resulting instruction is #ENC#%%%12653683091245%%Smith,James%. 

The $IC command specifies the information to be stored in the chip's memory. 
The card operating system record 924 is used to translate the instructions in the 
personalization equipment record into the programming control commands for the 
operating system. A control sequence, #\@#, is used to notify the personalization 
equipment that the data that follows is chip data. The first field to be stored is the chip 
identifier, ICCID. The system 100 interprets the WRITE tag in the personalization 
equipment record 926 in accordance with the command identified with the WRITE tag 
in the card operating system record 924. Since no offset value is specified in the 
application record 922 for the chip identifier entry, the default of "0000" is loaded into 
the %0 variable parameter field. The %L variable parameter field is set to the value of 
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the SIZE field in the $CHIP entry in the card framework template, i.e., "10" or 
hexadecimal "OA." The %D variable parameter field is set to the value of ICCID, 
"1234509876". The resulting command is A0D000000A1 234509876. 

The next commands cause the card operating system to store the cardholder 

5 name into the account name file in the account directory on the chip. The system 100 
translates the SELECT ACCT command into the corresponding card operating system 
command. The system 100 locates the SELECT entry in the card operating system 
record 924, the ACCT entry in the card framework template record, and substitutes the 
specified directory path for the account directory defined in the ACCT entry, i.e. 

10 "5F 1 0," for the %F variable parameter field in the command defined in the SELECT 
entry. The resulting command is AOA40000025F10. Similarly, the SELECT NAME 
command causes the system 100 to substitute the account name file "6F00" for the %F 
variable parameter field. The resulting command is A0A40000026F00. The final 
command in this series is the WRITE command. The system 100 interprets the WRITE 

1 5 command by substituting the default offset of "0000" for %0, the value of the SIZE 

field, "30" or hex "IE," as defined by the NAME entry in the card framework template 
record for %L, and the cardholder's name, "Smith,James" for the first sample 
cardholder data record 952, for %D, to produce the command 

A0D00000 lESmith, James— ~~ where each "~" represents a trailing 
20 space inserted to pad the name out to thirty characters. 

The system 100 processes the remainder of the commands in the personalization 
equipment record 926 in a similar fashion to produce a contiguous string of data 
containing the commands to issue a card for the first sample cardholder data record 952: 

#\@#AODOOOOOOA123459876AOA40000025F10AOA40000026FOOAOD 
25 000001ESmith,James— — ™~~~A0A40000026F10A0A40 

00002E12653683091245AOA40000026F2040998. 
The $PR command causes the system 100 to send the command data stream to the 
personalization equipment. 
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The data layouts shown in Figures 1 1, 12 and 13, and the sample data discussed 
in conjunction with the above example are only examples used to illustrate the 
functioning of various embodiments of the smart card personalization system 100. That 
the layouts and data are necessarily defined by the environment in which they are used 
will be apparent to those skilled in the art. 

As will also be apparent to those skilled in the art, the smart card personalization 
system 100 encompasses alternate embodiments of the software program in which the 
functions of the system are performed by modules different than those shown in the 
Figures. The system 100 may process the data in a serial or parallel fashion, or a 
combination of the two, without departing from the spirit or scope of the invention. The 
software program may be written in one of several widely available programming 
languages and the modules may be coded as subroutines, subsystems, or objects 
depending on the language chosen. Similarly, data used by the system 100 is described 
and represented as logical records embodied in a database but the invention is not 
limited to the described arrangement of data records, nor is the use of any particular 
type of data management system implied. Relational database systems from vendors 
such as Oracle, Sybase, Informix, or Microsoft provide the necessary infrastructure for 
managing the underlying data in the system, whether it is centralized or distributed, but 
other organizational data structures, i.e., indexed flat files, may be substituted without 
exceeding the scope of the invention. 

Furthermore, alternate embodiments of the invention which implement the 
system in hardware, firmware, or a combination of both hardware and software, as well 
as distributing the modules and/or the data in a different fashion will be apparent to 
those skilled in the art and are also within the scope of the invention. 

It is to be understood that the above description is intended to be illustrative, and 
not restrictive. Many other embodiments will be apparent to those of skill in the art 
upon reviewing the above description. The scope of the invention should, therefore, be 
determined with reference to the appended claims, along with the full scope of 
equivalents to which such claims are entitled. 
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What is claimed is: 

1 . A method for issuing portable programmed data carriers comprising the steps of: 
acquiring a personalization equipment identifier and personalization data for a 

5 cardholder from a card issuer management system; 

acquiring equipment characteristic data for a personalization equipment type from a 

record in a database identified by the personalization equipment identifier; and 
transferring the personalization data to the personalization equipment as specified 

by the equipment characteristic data to issue the data carrier. 

10 

2. The method of claim 1, further comprising the step of translating the 
personalization data into an internal format such that the translated personalization data 
is transferred to the personalization equipment. 

15 3 . The method of claim 2, wherein the personalization data is translated from a format 
defined by the card issuer management system into the internal format in accordance 
with format template data. 

4. The method of claim 3, further comprising the step of acquiring the format template 
20 data from a record in the database identified by a data format identifier supplied by the 

card issuer management system. 

5 . The method of claim 3 , further comprising the step of acquiring the format template 
data from the card issuer management system. 

25 

6. The method of claim 3, further comprising the step of acquiring the format template 
data from an application data record in the database identified by an application 
program identifier supplied by the card issuer management system. 
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7. The method of claim 1, further comprising the steps of : 
collecting information regarding the issuing of the data carriers; and 
reporting statistics derived from the collected information to the card issuer 

management system. 

8. The method of claim 1, further comprising the steps of: 

acquiring an application program identifier from the card issuer management 
system; 

acquiring application data from a record in the database identified by the application 

program identifier; and 
transferring the application data to the personalization equipment as specified by the 

equipment characteristic data. 

9. The method of claim 1, further comprising the steps of: 
acquiring security data from a security source; and 

transferring the security data to the personalization equipment as specified by the 
equipment characteristic data. 

10. The method of claim 1, further comprising the steps of: 

acquiring a card operating system identifier from the card issuer management 
system; 

acquiring programming control commands from a record in the database identified 

by the operating system identifier; and 
transferring the programming control commands to the personalization equipment 

as specified by the equipment characteristic data. 

11. The method of claim 10, further comprising the steps of: 

acquiring an application program identifier from the card issuer management 
system; 
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acquiring the application data from a record in the database identified by the 

application program identifier; and 
transferring the application data to the personalization equipment as specified by the 

equipment characteristic data. 

5 

12. A system for issuing portable programmed data carriers comprising: 

a card issuer management system interface for acquiring a personalization 

equipment identifier and personalization data for a cardholder from a card 
issuer management system; 
10 a personalization equipment interface for acquiring equipment characteristic data 

for a personalization equipment type from a record in a database identified by 
the personalization equipment identifier; and 
the personalization equipment interface for further transferring the personalization 
data to the personalization equipment as specified by the equipment 
1 5 characteristic data to issue the data carrier. 

13. The system of claim 12, wherein the card issuer management system further 
acquires a format template data from a record in a database identified by a data format 
identifier supplied by the card issuer management system and translates the 

20 personalization data into an internal format from a format defined by the format 

template data such that the personalization equipment interface transfers the translated 
personalization data to the personalization equipment. 

14. The system of claim 12, further comprising a tracking/report engine for collecting 
25 data from the system regarding the issuing of the data carriers and for reporting the 

collected data to the card issuer management system. 

15. The system of claim 12, further comprising: 
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a card application interface for acquiring application data from a record in the 

database identified by an application program identifier acquired by the card 
issuer management system interface; and 

the personalization equipment interface for further transferring the application data 
5 to the personalization equipment as specified by the equipment characteristic 

data. 



16. The system of claim 12, further comprising a security manager for acquiring 
security data from a security source and transferring the security data to the 
1 0 personalization equipment interface. 



17. The system of claim 12, further comprising: 

a card operating system interface for acquiring programming control commands 
from a record in a database identified by a card operating system identifier 
1 5 acquired by the card issuer management system interface; and 

the personalization equipment interface for further transferring the programming 
control commands to the personalization equipment as specified by the 
equipment characteristic data. 



20 18. The system of claim 17, further comprising: 

a card application interface for acquiring application data from a record in the 
database identified by an application program identifier acquired by the card 
issuer management system interface; and 
the personalization equipment interface for further transferring the application data 
25 to the personalization equipment as specified by the equipment characteristic 

data. 



19. A data structure stored on a storage device for producing portable programmed data 
carriers comprising a plurality of personalization equipment elements, wherein each 
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personalization equipment element is addressed by a unique personalization equipment 
identifier and specifies operating parameters for a type of personalization equipment 
such that the personalization data is properly formatted for transmission to the 
personalization equipment used to issue the data carrier. 

5 

20. The data structure of claim 19, further comprising a plurality of data format 
elements, wherein each data format element is addressed by a unique data format 
identifier and specifies a template used by a card issuer to format personalization data. 

10 21 . The data structure of claim 19, further comprising a plurality of card operating 

system elements, wherein each card operating system element is addressed by a unique 
card operating system identifier and specifies programming control commands for 
transmission to the personalization equipment. 

15 22. The data structure of claim 19, further comprising a plurality of application program 
elements, wherein each application program element is addressed by a unique 
application program identifier and specifies application data used by a particular type of 
application program for transmission to the personalization equipment. 

20 23. The data structure of claim 22, further comprising a plurality of card operating 

system elements, wherein each card operating system element is addressed by a unique 
card operating system identifier and specifies programming control commands for 
transmission to the personalization equipment. 

25 24. A system for issuing portable programmed data carriers comprising: 

personalization equipment receiving a data stream and in response thereto 

personalizating portable programmed data carriers; 
personalization data obtained froma card issuer management system; and 
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a smart card personalization system having a database containing one or more data 
elements selected from the group consisting of 
data format template elements, 
card application data elements, 
5 card operating system elements, 

and personalization equipment elements, 
wherein the smart card personalization system outputs the data stream as a 
result of processing the personalization data as directed by the selected data 
elements. 
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Abstract of the Disclosure 
A smart card personalization system maintains a database containing card issuer 
data format templates, card applications, card operating system commands, and 
personalization equipment specifications and provides a centralized interface of inputs 
5 and outputs to a card issuing process which dynamically adjusts to changes in the 

issuing process to easily permit a card issuer to change data formats, card applications, 
card operating systems and/or personalization equipment in a card issuing process. The 
system interfaces to any card issuer management system, manages the transfer of 
cardholder data and card applications to the particular personalization equipment used, 
10 and maintains statistics for real-time and off-line inquiries to support critical 

management and reporting functions. Furthermore, the system works with a variety of 
security methodologies to prevent fraud. 

15 
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SCHWEGMAN, LUNDBERG, WOESSNER & KLUTH, P.A. 

United States Patent Application 

COMBINED DECLARATION AND POWER OF ATTORNEY 

As a below named inventor I hereby declare that: my residence, post office address and citizenship are as stated below next to my 
name; that 

I verily believe I am the original, first and joint inventor of the subject matter which is claimed and for which a patent is sought on 
the invention entitled: SYSTEM AND APPARATUS FOR SMART CARD PERSONALIZATION . 

The specification of which is attached hereto. 

I hereby state that I have reviewed and understand the contents of the above-identified specification, including the claims, as 
amended by any amendment referred to above. 

I acknowledge the duty to disclose information which is material to the patentability of this application in accordance with Title 37, 
Code of Federal Regulations, § 1.56 (see page 3 attached hereto). 

I hereby claim foreign priority benefits under Title 35, United States Code, § 1 19/365 of any foreign application^) for patent of 
inventor's certificate listed below and have also identified below any foreign application for patent or inventor's certificate having a filing 
date before that of the application on the basis of which priority is claimed: 

No such applications have been filed. 

^ I hereby claim the benefit under 35 U.S.C. § 1 19(e) of any United States provisional application(s) listed below. 

U.sMerial No. 60/015,743, filed April 15, 1996, entitled SYSTEM AND APPARATUS FOR SMART CARD PERSONALIZATION . 

1J I hereby claim the benefit under Title 35, United States Code, § 120/365 of any United States and PCT international application(s) 
list^below and, insofar as the subject matter of each of the claims of this application is not disclosed in the prior United States application 
m4t3kianner provided by the first paragraph of Title 35, United States Code, § 1 12, 1 acknowledge the duty to disclose material information 
as defined in Title 37, Code of Federal Regulations, § 1.56(a) which occurred between the filing date of the prior application and the national 
or PCT international filing date of this application. 

No Ijfch applications have been filed. 

jc I hereby appoint the following attorney(s) and/or patent agent(s) to prosecute this application and to transact all business in the 
Pate|| and Trademark Office connected herewith: 

Anglfii, J. Michael 
Bianchi, Timothy E. 
Bifflg, Patrick G. 
BHIion, Richard E. 
Brennan, Thomas F. 
Burke, John E. 
Clark, Barbara J. 
Dryja, Michael A. 



Reg. No. 24,916 


Embretson, Janet E. 


Reg. 


No. 


39,665 


Lempia, Bryan J. 


Reg. No. 


39,746 


Reg. No. 39,610 


Fogg, David N. 


Reg. 


No. 


35,138 


Litman, Mark A. 


Reg. No. 


26,390 


Reg. No. 38,080 


Forrest, Bradley A. 


Reg. 


No. 


30,837 


Lundberg, Steven W. 


Reg. No. 


30,568 


Reg. No. 32,836 


Holloway, Sheryl S. 


Reg. 


No. 


37,850 


Schwegman, Micheal L. 


Reg. No. 


25,816 


Reg. No. 35,075 


Kalinowski, Leonard J. 


Reg. 


No. 


24,207 


Slifer, Russell D. 


Reg. No. 


39,838 


Reg. No. 35,836 


Klima-Silberg, Catherine I. 


Reg. 


No. 


40,052 


Viksnins, Ann S. 


Reg. No. 


37,748 


Reg. No. 38,107 


Kluth, Daniel J. 


Reg. 


No. 


32,146 


Woessner, Warren D. 


Reg. No. 


30,440 


Reg. No. 39,662 


Lemaire, Charles A. 


Reg. 


No. 


36,198 





I hereby authorize them to act and rely on instructions from and communicate directly with the person/assignee/attorney/ 
firm/organization/who/which first sends/sent this case to them and by whom/which I hereby declare that I have consented after full 
disclosure to be represented unless/until I instruct Schwegman, Lundberg, Woessner & Kluth, P.A. to the contrary. 

Please direct all correspondence in this case to Schwegman, Lundberg, Woessner & Kluth, P.A. at the address indicated below: 

P.O. Box 2938, Minneapolis, MN 55402 
Telephone No. (612)339-0331 



OurRef.457.O03USl 
Serial No, not assigned 
Filing Date: not assigned 
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I hereby declare that all statements made herein of my own knowledge are true and that all statements made on information and 
belief are believed to be true; and further that these statements were made with the knowledge that willful false statements and the like so 
made are punishable by fine or imprisonment, or both, under Section 1001 of Title 18 of the United States Code and that such willful false 
statements may jeopardize the validity of the application or any patent issued thereon. 



Full Name of joint inventor number 1 : David R. Tushie 
Citizenship: United States of America 

Post Office Address: _ 1 1 145 Branching 

Eden/Prairk 

(// / ; 

Signature: 



Residence: Eden Prairie, MN 





Date: 



David R. Tushie 



Full Name of joint inventor number 2 : William W. Haeuser 

Citizenship: United States of America Residence: Chaska, MN 

Post Office Address: 2750 Autumn Woods Drive 

Chaska, MN 55318 



Signature: 

^ William W. Haeuser 



FuMSfame of inventor: 

cMenship: Residence: 
P^st Office Address: 



Sgiature: _ — Date: 



Full Name of inventor: 

Citizenship: 

Post Office Address: 



Residence: 



f 
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§ 1.56 Duty to disclose information material to patentability. 

(a) A patent by its very nature is affected with a public interest. The public interest is best served, and the most effective patent 
examination occurs when, at the time an application is being examined, the Office is aware of and evaluates the teachings of all information 
material to patentability. Each individual associated with the filing and prosecution of a patent application has a duty of candor and good 
faith in dealing with the Office, which includes a duty to disclose to the Office all information known to that individual to be material to 
patentability as defined in this section. The duty to disclose information exists with respect to each pending claim until the claim is 
cancelled or withdrawn from consideration, or the application becomes abandoned. Information material to the patentability of a claim that 
is cancelled or withdrawn from consideration need not be submitted if the information is not material to the patentability of any claim 
remaining under consideration in the application. There is no duty to submit information which is not material to the patentability of any 
existing claim. The duty to disclose ail information known to be material to patentability is deemed to be satisfied if all information known 
to be material to patentability of any claim issued in a patent was cited by the Office or submitted to the Office in the manner prescribed by 
§§ L97(b)-(d) and 1.98. However, no patent will be granted on an application in connection with which fraud on the Office was practiced or 
attempted or the duty of disclosure was violated through bad faith or intentional misconduct. The Office encourages applicants to carefully 
examine: 

(1) prior art cited in search reports of a foreign patent office in a counterpart application, and 

(2) the closest information over which individuals associated with the filing or prosecution of a patent application believe any 
pending claim patentably defines, to make sure that any material information contained therein is disclosed to the Office. 

(b§ Under this section, information is material to patentability when it is not cumulative to information already of record or being 
madsypf record in the application, and 

* ( 1 ) It establishes, by itself or in combination with other information, a prima facie case of unpatentability of a claim; or 

„ (2) It refutes, or is inconsistent with, a position the applicant takes in: 

" ~ (i) Opposing an argument of unpatentability relied on by the Office, or 

ij (ii) Asserting an argument of patentability. 

A pFgha facie case of unpatentability is established when the information compels a conclusion that a claim is unpatentable under the 
preponderance of evidence, burden-of-proof standard, giving each term in the claim its broadest reasonable construction consistent with the 
specification, and before any consideration is given to evidence which may be submitted in an attempt to establish a contrary conclusion of 
patefflability. 

(c) Individuals associated with the filing or prosecution of a patent application within the meaning of this section are: 

( 1 ) Each inventor named in the application: 

(2) Each attorney or agent who prepares or prosecutes the application; and 

(3) Every other person who is substantively involved in the preparation or prosecution of the application and who is associated 
with the inventor, with the assignee or with anyone to whom there is an obligation to assign the application. 



(d) Individuals other than the attorney, agent or inventor may comply with this section by disclosing information to the attorney, 
agent, or inventor. 



